突撃！隣のDevOps 【リブセンス編】
久々の「突撃！隣のDevOps」の記事です。今回はリブセンスの「転職会議」を開発している部署にDevOpsに対する取り組みや考え方、組織文化についてインタビューしてきました。
今までのシリーズとは異なりリブセンスに伺わずにリモートでのインタビューでした。 なので突撃もしておらず、会社の位置関係的にもそこまで隣じゃないDevOpsです。
リブセンスについて
まずはリブセンスがどのような会社でどのような業務を行っているか、インタビューの担当者様について紹介してきます。
サービス内容
人材領域・不動産領域といった、人生の大きな意思決定が必要になる場面での情報の非対称性を課題ととらえ、それを解決するようなサービスを運営しています。口コミによる企業情報の透明化・マッチング精度向上に挑む「転職会議」、エンジニアの競争入札型転職メディア「転職ドラフト」、成功報酬型でより多くの求人案件から適職を提案する「マッハバイト」「転職ナビ」、住宅の適正価格や災害リスク情報を提供する「IESHIL」などがあります。最近は新規事業の立ち上げも行っています。
詳しい内容は「リブセンスの事業」にまとめられていますので、そちらも是非ご覧になってください。
インタビューに答えていただいた方
転職口コミサイト「転職会議」の開発グループのエンジニアの皆さんにお越しいただきました。転職会議では4つのスクラムチームにエンジニアが3、4名アサインされ、他にSREチームがある開発体制です。 今回は様々なロールの方にインタビューすることができたので、まずは担当者についてご紹介していきます。
- かたいなかさん 基盤構築の業務、SLOの策定などをSREチームの一員として行っている。直近では重要なミッションであった基盤のEKS化を推進した。 「転職会議」ではインフラ基盤としてAWSを利用している。そのためRIを購入したり、リソースをTerraformで管理して、日々更新などの業務も行っている。
- 中村さん エンジニアリングマネージャーとしてチームの管理をしている。そのため「転職会議」におけるエンジニアリソースや、プライオリティを考慮したロードマップ作成、メンバーとの 1on1や採用活動などを中心に行っている。
- 岡さん 開発を行いつつ、スクラムマスタとしての業務をこなしている。スクラムマスタとしてはプロダクトオーナーと企画を詰める際に、エンジニア視点での実行可能性や見積もり概算を行っている。
- 城川さん、水谷さん 「転職会議」のアプリケーションを実際に開発している。新機能の開発・レガシーなコードをリファクタ・パフォーマンス面に課題がある箇所のチューニングなどの業務を担当。「転職会議」ではフロントエンド、バックエンドなどの垣根はなく開発をしている。 チームは、ドメインや関心事で4つのチームに分かれて開発を行っている。施策のロードマップで重点対応したい施策とエンジニアがやりたいことが合致した場合にチームアサインの調整を行うなどの特徴もある。
SREとして考える2社の違いについて
お話を伺ったかたいなかさんは現在はリブセンスに在籍していますが、過去にはクラスメソッドで働いていました。そんなかたいなかさんに2社の違いについて聞いてみました。
— かたいなかさんは元々はクラスメソッドにいらして、SREとしてリブセンスに転職しています。 両社の組織や文化の違いについてお伺いしても良いでしょうか？
クラスメソッドは、AWSの技術力でお客様企業のビジネスを助ける会社であり、技術のスペシャリストがたくさん揃っている会社でした。B2B2Cという形であるため、カスタマーに対して直接価値を届けることは難しかった一方で、技術力を通じて他社のエンジニアがカスタマーに対して価値提供するのを手助けするのが主だったのかなと思います。 一方でリブセンスは事業会社であるため、自分たちが構築したWebシステムによって直接カスタマーに価値を届けることができます。プロダクトエンジニアの方が、デザイナーやPdMと協力しながら、自分のクエリで出した数値予測を元に施策を提案・実行し、結果を計測していたり、ビジネスを意識して主体的に動いていたのを見てカルチャーショックを感じました。
SREとしては、クラスメソッドでは自分が使いたい技術やお客様が必要とする技術に焦点を当てて仕事をしていました。浅く、広く様々な技術に触れられました。
リブセンスに入社後は、技術の採用から運用まで自分で面倒を見ることになるため、今まで使っていた技術に対してもさらに深い理解が求められるようになりました。周りのエンジニアの方は自然とそういった事ができているため、周りから学ぶことが多かったです。(かたいなか)
DevOpsについて
組織として持っていた越境文化と事業会社としてどのように価値を出し差別化してきたかの結果が自然とDevOpsの枠組みに近かったという印象でした。
— リブセンスの考えるDevOpsの定義はどのようなものですか？
DevOpsという言葉を部署内で意識的に使っているわけではないので、はっきりと定義を持っているわけではありません。強いて言えば事業部内でインフラの管理を完結させてスムーズな開発を行えるようにした結果だと考えています。詳細を記載するとビッグデータ基盤を使って仮説を立て、A/Bテスト等で仮説を検証し、CI/CDでスムーズに新機能を世に出し、監視で問題が発生したらすぐに気づく、これらの一連のサイクルとそれを支えられる体制だと考えています。
ただ、DevとOpsを意識しない状態を目指しています。リブセンスでは「越境」という文化があり問題解決のために職種や専門分野に縛られることなく、どんどん隣の領域にも目を向けて行くことを良しとしています。(かたいなか)
— ビッグデータを利用して仮説を立ててリリースし、問題を発見したらすぐに気づく体制ということが1つ特徴的ですね。この部分はどのように行っていますか？
リブセンスアナリティクスという基盤を持っており、そこにユーザの行動記録を保存しています。 それらのデータを元に仮説の立証を行い、検証と今後への活用をしています。 企業データと口コミデータの見せ方を生のデータをそのまま見せるのと、サマリーを統計情報として最初に表示した場合の違いを例として仮説を立ててみます。よくあるように口コミを1件ずつ全て表示すると、ユーザが全て閲覧するのに時間がかかってしまいます。それに対してサマリーを表示した場合はユーザが口コミを閲覧する前にマインドマップを作れます。なので必要な情報に当たりやすくなります。 このようにビッグデータ基盤を元に問題を把握して仮説の立証から検証ができるようにしています。(水谷) アジャイルの考えにも通じますが、開発時は目に見える動くものを小さく作ってユーザーからのフィードバックを早く得ることを心がけています。調査や分析に基づいた仮説をもとにまずはMVPを定義して実装し、後から仮説と共にブラッシュアップしていくようなイメージです。(城川)
— 仮説決定から施策策定までエンジニアも携わっているという認識ですが、具体的にエンジニアはどのようなことをしていますか？
ビッグデータ基盤にアクセスしてグラフを作り分析するというのはPdMの方が優れているので適宜分担しつつではありますが、PdMが中心に行っています。アプリケーションエンジニアはコードを書いている時間が多いので、ログをどのように、どのタイミングで残せば検証しやすいかを考えてコーディングを行い支援しています。 ただし、アプリケーションエンジニア個人でもデータ分析に関心がある人は自分の仕事として事業の数値を追って解析などをしています。そのようにエンジニアから行動をしてPdMに提案をしたりもしています。 エンジニアがやりたいことを行える組織の特徴が表れているかもしれませんね。(中村)
越境とエンジニアについて
— DevとOpsをどのように連携させていますか？
基本的にはSREが基盤を整えつつ開発者がセルフサービスでインフラを変更しています。一般的にDevOpsで意識される実装、デプロイ、監視の流れをほぼ開発者たちが行っておりTerraformやKubernetesのマニフェストなどを必要に応じてSREがレビューしています。得意分野や役割によってDevとOpsを担当する割合は異なりますが、どちらかだけをやる人はおらずアプリケーション開発者もパフォーマンスなどを意識して実装をしています。(かたいなか)
— SREはどのように開発者側に越境していますか？
開発のどこが滞っているかが見えやすい環境なので、課題を見つけて、開発者が開発しやすいように先回りして基盤を作っていくことを意識しています。 また、従来のブランチデプロイを使用したフローだと、開発やステージング環境にデプロイが終わるまで開発フローが止まってしまうため、今はKubernetes基盤でのプレビュー環境を実装しようと進めています。 開発者が自走できるという点で言うとSREとしての仕事がなくなるのが理想的な状態と考えています。基盤側を見る人数を最小限にして開発へのリソースを増やすことでよりビジネス的に有意になります。そして開発の中で発生した問題をチームとして自発的に解決できればより理想的かと思っています。今考えているのはSLOのしきい値等を決める権限を開発者に引き渡していくことでこの部分についても自走を目指しています。(かたいなか)
— 直近でECSからEKSへ基盤を移行していますね。SREチームからの提案だったそうですが、インフラの変更やデプロイフローの変更に抵抗はありませんでしたか？
ありませんでした。SRE以外のエンジニアもKubernetesへの興味が強く、技術獲得のサポートをしていただいて感謝しています。そして新しいインフラを作りたい時、質問しやすい相手としてSREがいます。心理的安全性が担保されています。(岡)
SREとしても勉強会の他に、プロダクトエンジニアに自分たちが開発しているECSで動いているサービスをSREチーム助言のもとでEKSに移行してもらうなど、アプリケーション開発者が自走できるEKS基盤となるよう全力でサポートしました。(かたいなか)
— 各開発チームが自発的に動くことが特徴と伺っています。実際にどのようなことをしていますか？
開発はスクラムガイドに則ったイベント(デイリー、プランニング、レトロスペクティブ)で進めています。その中でタスクは全てプロダクトオーナーから降ってくるのではなく、スクラムチーム内でタスクを決めることも多いです。例えば負債返却とか技術選定をスクラムチーム発で必要に応じてビジネスを巻き込んだり、他チームのエンジニアを巻き込んだりして策定しています。個人のタスクも「個々人がやりたいこと」と「チームが求めていること」を期初に上長とすり合わせるので、ある程度自由に開発してもチームの方針とずれづらく、挑戦することに対する心理的安全性が担保されているように思います。(岡)
— レガシーシステムからの移行を含めて、新しい技術を早い段階から採用していますが、モチベーションは何ですか？
一番のモチベーションは技術的興味かと思います。やってみようよと挑戦する文化もあります。また、アプリケーションが適度にマイクロサービス化されています。ですので小さく試せてその上コンテナとして動かせるという点が技術的な挑戦をするのにいい影響を与えています。(水谷)
— 話題が大きく変わりますが、新メンバーへのキャッチアップの支援をどのように行っていますか？
中途入社の場合、マネージャーから参画するプロジェクトと組織の説明を受けた後に、メンターと共に実務を進めていきます。そのメンターから開発の仕方を学んだり、定期の1on1でのフォローを受けられる体制になっています。メンターと新メンバーは同じチームで同じ仕事内で開発を進めていくので、メンターへの大きな負荷にはならないようになっています。 新卒には別途新卒エンジニア向けの研修が半年ほどあります。研修には卒業要件があり、きちんと要件を満たした段階で開発案件にアサインされるので、比較的キャッチアップは早いです。新卒研修も試⾏錯誤しているので随時改善されています。(中村)
リブセンスの文化と組織
— 技術に対して非常に挑戦的な印象を受けています。会社としてどのようなサポートがありますか？
リブセンスでは自分のリソースのうち10%を技術投資に割り当てなけらばいけないという義務があります。どうしても通常の業務だけでは新しいことを学べなくなりがちなので、この投資義務があることで、人によっては新技術を学習しやすいのかもしれません。また学習する内容も新言語やフレームワークのみならず、イベントの開催準備(ハッカソンを開催するための学習や環境準備)など様々です。(中村)
またマネージャー以外のロールであっても評価されるように、4つのエンジニアロールのどれに注力するのか割合を決め、目標を設定します。目標を期始に策定して上司とのコミュニケーションパスとして利用することが多いです。ロールとしては「プロダクトエンジニア」「エンジニアリングマネージャー」「テックリード(組織への技術浸透を求めている)」「スペシャリスト(自分の技術をとことん追い求めている)」があります。スペシャリストとテックリードを7:3やプロダクトエンジニアとエンジニアリングマネージャーを半分ずつといったように決定します。(中村)
— 取り組みや文化でエンジニアの挑戦を可能にしていますね。エンジニア間で知識をどのように共有していますか？
技術的な取り組みをエンジニア間で評価し合う「Tech Award」という取り組みがあります。「エッジ」「レガシーマイグレーション」「やらかし」の3部門でそれぞれエントリーしてアワードを決定します。この取り組みで他の部署がどのようなことをやっているかの相互理解ができますし、取り組みと失敗をオープンに共有できる心理的安全性の高さを示していると思います。また転職会議事業部ではユーザーに影響がある障害が発生した時などにポストモーテムを書いています。直近ではエンジニア有志でポストモーテムの読書会を実施して、不具合の知見の共有やシステム開発を行う上での課題意識の共有（例:ここら辺のコード壊れやすいよね、テストが少なくて開発がやりづらいよね、など）をさらに押し進めようとしています。(城川)
プラクティスとツール
Kubernetesを利用しておりGitOpsに基づくCI/CDの実践をしているのが特徴的でした。
— CI、デプロイ、構成管理をどのように行っていますか？
Fluxを利用してGitOpsに基づくCI/CDを実践しています。CIツールにはCircleCIを、デプロイにはChatOpsのための独自ツールとFlux(Weave Cloud)を利用しています。また構成管理のためにTerraformとDocker、一部Ansibleを利用しています。(かたいなか)
— 自動テストは、どのレイヤにどの程度行っていますか？
各リポジトリにユニットテスト、APIなどはRequestテストを用意しています。 マージ前にはCircleCIによりテストを行っています。(岡)
— デプロイはどのような方法で行っていますか？
アプリケーションイメージはSlackのチャットボットからコマンドが叩かれたタイミングでFluxにリクエストが飛びデプロイをするようにしています。またTerraformはCircleCIを利用してデプロイを行っています。PRの状態でステージング環境を占有せずに動作確認できるプレビュー環境も作成を進めています。詳細については下記ブログをご閲覧してください。(かたいなか)
— 障害をどのように検知して、どのような対応フローで進めていますか？
即時対応が不要なアラートはSlackに集約しています。ツールをあげると「Datadog」「Sentry」「Cronitor」「Rollbar」などを利用しています。Datadogで発生したアラートの中でも外形監視、優先度を上げて対応したいアラートはOpsgenieを経由して電話させています。基本的に電話がくるものは即時対応できるようにしていますが、そこまで頻繁にアラートはあがりません。障害対応時には専用のチャンネルでやりとりし、ログ、判断の記録を書いていくようにしています。 EKSを採用しているためシステムコンポーネントで動かすのですが、不具合が起きたときに監視で検知できるかを意識しています。もし監視で検知できない場合はOSSに対してPRを送ってPrometheusのエンドポイントをはやしてもらったりしています。(かたいなか)
— どのようなメトリクスを取得して、どのように改善をおこなっていますか？
まずインフラ側のメトリクスですがサーバサイドのレイテンシやエラー率、フロントエンドではWeb Vitalsのメトリクスを基にしてSLOを定義しています。違反したときには優先度を上げて対応してもらえるよう取り組んでいます。SREとしては、半年に1度アンケートを実施して、その内容を元に次の半年に⾏うことを決めています。(かたいなか)
次にビジネス的なメトリクスについてです。全体感として、まず売り上げをKGIにして全てが繋がるようにKPIツリーを定義しています。予算とKPIの接続は主にチーフプロダクトマネージャーが見ており、目標に対して差分のある部分がプロジェクトになり、そこの数値は職種問わずプロジェクト内で頻繁に確認しています。メルマガはメール開封率・メルマガ内の求人クリック率・求人ページ遷移後の応募率を確認しています。開封される可能性の低いメールの傾向を調べて不必要なメールは送らなくしたり、横断組織に所属している機械学習エンジニアと組んで求人レコメンドを改良するなどの改善を行っています。求人情報はユーザー調査結果や今後打ち出していきたいビジネス価値に基づいてページ全体のリニューアルをしつつ、Google Optimizeを活用したA/Bテストを細かく積み重ねて応募ボタンクリック率を改善しています。このようにデータに基づいてアプリケーション部分も改善を行っています。(水谷)
最後に
越境文化と数値に基づいて動く組織というのがとても特徴的で理想的だと感じました。 お忙しい中インタビューに協力していただきありがとうございました。
「リブセンスではエンジニアを募集しています。裁量が大きく、声を挙げれば様々なことにチャレンジできる環境です。プロダクトマネジメントを行うエンジニア、テクニカルリード、エンジニアリングマネージャー、技術スペシャリスト等様々なキャリアパスが用意されています。技術でプロダクト改善をしていくことに興味のある方、一緒に働きましょう！カジュアル面談からお待ちしています。」とコメント頂きました。採用ページはこちらです。
